1.3. General Summary

During our testing event at UC Berkeley two vendors participated. This was the fourth in a series of interoperability testing events for RFC 2445, 2446, and 2447. The first two were “onsite” events and the third was a “virtual” event with testing occurring via conference calls and email testing.

At the last three testing events, the testing done was more at a vendor to vendor level rather than at a pure IETF “RFC Conformance” level. By Conformance testing, we mean identifying support for and testing explicit MUST/MUST NOT/SHOULD/SHOULD NOT/ and MAY requirements.

In preparation for this interop event and to satisfy the requirement for RFC conformance testing, a matrix of all three RFC’s was prepared and this was used as our driver for testing compliance. We, as a group, went through each and every item and validated whether the requirement was supported by each vendor. In most cases, where both vendors did not support a particular requirement, we still tested the action to validate this “non-support.” From that perspective, this was probably the most productive interop of all the events.

Since there were only two participants at this interop, we will need at least one more interoperability event to fully identify what needs to be removed from these drafts. Now that we have a complete set of matrices as well as test scenarios and scripts, we can fully define what works and doesn’t work. I have included the notes from the other three events at the end of this document for comparison.

This document will highlight the key findings from this exercise. The matrix spreadsheet with all items noted is attached to this report. The spreadsheet shows what is and is not supported by the two participants. Based on past interops, and discussions held at this meeting we have ascertained the following:

  • Most vendors are not doing Journals. It appears we can probably remove any VJOURNAL items from all drafts without significant ramifications.

  • Recurring and repeating meetings still have a bit of mystery and ambiguity associated with them. This was obvious during testing and is well documented and discussed on the various lists. We talked about the differences between recurring and repeating meetings and we look to see this discussed further on all the mailing lists.

  • VTODO‘s are not supported by either vendor and there were problems in past interops. This may be something that can be removed and added back as another draft that just pertains to VTODOs.

The next page identifies the items that are supported by both vendors and the items not supported on the three drafts. Note — there are 201 specific items in RFC 2445, 74 items in RFC 2446, and 14 items in RFC 2447. Any item not shown on the summary page means only one of the two vendors during this interoperability event supports that item.

I created a table that counts the number of items supported and not supported by both vendors as well as a breakdown of how many of each item each vendor does or does not support. I also created a table that shows the specific items supported by both vendors and a table showing the specific items NOT supported by both vendors.

In summary, we are farther along than we were during the first interop. But we have a ways to go. There was discussion at this interop about opening a new mailing list to work on simplification of these drafts in order to improve/enhance interoperability opportunities.

The results for both vendors showed the following:

Draft

Items Supported

Items Not Supported

RFC 2445

114

26

RFC 2446

15

5

RFC 2447

8

5

By Vendor, the numbers look like this:

Draft

Items Supported

Items Not Supported

Vendor 1

RFC 2445

132

69

RFC 2446

35

39

RFC 2447

9

5

Vendor 2

RFC 2445

137

64

RFC 2446

45

29

RFC 2447

8

6